I am getting the error on simulator with iPadOS config (iPad Pro 12.9-9inch). Running on a physical iPad - error does not occur. Simulator is running on an iMac (24-inch, M1, 2021)

FB9642891

Fixed the issue and installed xCode 13 by deleting the Norton Security App. By the way - the new permission setting procedure to enable system extensions is interesting.. It is shutdown, restart into the OS Recovery environment, then enable kernel extensions from a Security Policy button. More than one confirming admin password entry is required. It's fine with me, I like security !

I successfully installed xCode 13 after experiencing the same issue by deleting Norton from the machine. After xCode installed okay then reinstall Norton. Also to stop the retry cycle of down load, install, crash I removed xCode temp files from the Application folder, then reinstalled the older version of xCode from backup drive.

The "+" button for the "installed" attribute checkbox will open the popup window for setting size classes on a constraint.

My solution: Add a struct with the same var names as the CoreData Entity class. Add one more var to hold the NSManagedObjectID. Add a method (#asStruct) to copy all of the values in the Entity class to the struct. Everywhere the Entity class was used, change the reference to the new struct. Finally on the save operation use the NSManagedObjectID to get the managed object back from the data context and update the managed object values as needed from the struct. Only one of the 18 CoreData entity classes needed this fix. The other 17 lower level entities apparently did not cross the NSDiffableDataSourceSnapshot/Entity class isolation boundary and thus do not cause the 'Sendable' warning. It would be nice if the CoreData data model supported an option to create either a struct or an Entity class. This would (I guess) save a lot of code changes where two frameworks have interfaces.

New version (iOS 18.1.1) problem with cloudIdentifierMappings(forLocalIdentifiers:) is causing me dataStore errors. The method is now acting like it has a completionBlock return . The initial return is with an error result. Inspecting a little later in the debugger shows a changed return with the expected cloudIdentifiers. You would think that wrapping it in the NSManagedObjectContext.performAndWait would be a quick fix.. but on my first try performAndWait did not improve the situation. Any ideas??? THANKS

Thanks to Quinn's extended explaination in another thread the problem is fixed by adding @Sendable to the Metal command queue command buffer's completion handler. The app is now running on Swift 6 commandBuffer.addCompletedHandler { @Sendable (_ commandBuffer)-> Swift.Void in ... The compiler team should consider adding information that can be used for correcting the problem. Right now the assert crash is completely cryptic to me and has no usable information about the cause. [(https://developer.apple.com/forums/thread/764777?answerId=807248022#807248022)]